La notation SysML

Introduction

Introduction

La matrice qui nous servira de "carte de base" pour placer les activités ou les modèles, sera celle-ci :

ExigencesStructureComportementTransverse

Organisation

Analyse

Conception

Implémentation

Points de vue

Dans un axe horizontal, j’ai différencié quatre grands points de vue :

Points de vue (Exigences)

Les exigences et leur prises en compte sont un élément critique pour le succès du développement de tout système. Sans explorer l’ensemble des activités d’ingénierie système (ce qui nécessiterait tout un volume du type de [reqs]) nous insisterons sur cet aspect.

requirements slide

Points de vue (Structure)

La description de l’architecture et des éléments constitutifs du système, avec les blocs, leurs relations, organisations internes, etc. constituera un point de vue important. C’est souvent la partie de modélisation qui pose le moins de problème aux débutants.

structure slide

Points de vue (Comportement)

Le comportement d’un système est du point de vue de l’utilisateur final beaucoup plus important que la structure elle-même. C’est la partie qu’il est la plus à même d’exprimer, de comprendre (vos modèles) et de valider.

comportement slide

Points de vue (Transverse)

Un certains nombre de concepts sont transverses aux trois points de vue précédents. Il s’agira principalement de parler de cohérence ou de traçabilité entre les phases de développement ou entre les points de vue.

transverse slide

Phase de développement

Dans un axe vertical, j’ai différencié quatre grandes phases du cycle de vie du développement :

Phase de développement (Organisation)

Une étape indépendante du type de cycle de développement envisagé (en V, agile, etc.) mais qui concerne la mise en place d’un cadre de travail qui permette un développement de qualité (outils, éditeurs, gestionnaire de version, de tâches, etc.).

On pourrait rapprocher cette étape du "cycle 0" de Scrum.

organisation slide

Phase de développement (Analyse)

Cette phase vise plutôt à examiner le domaine du problème. Elle se focalise sur les cahiers des charges et les exigences. L’analyse débouche sur un dossier d’analyse qui décrit les grandes lignes (cas d’utilisation, architecture principale) du système.

analysis slide

Phase de développement (Conception)

Cette phase vise plutôt à examiner le domaine de la solution. Elle débouche sur un dossier de conception qui décrit les détails conceptuels de la solution envisagée (structure détaillée, comportement, etc.)

design slide

Phase de développement (Implémentation)

Cette phase traite des développements finaux (construction ou approvisionnement en matériel, développement de codes, etc.).

implementation slide

Quizz break!

tuxteacher

Questions de révision

quizz1 quizz2

Révisions (suite)

Éléments de correction
acronymes cor

Révisions (suite)

quizz3

Pourquoi une nouvelle notation ?

Il existe une notation qui se veut "unifiée" pour les modèles : UML™. Néanmoins cette notation est peu adaptée pour l’Ingénierie Système :

Pourquoi une nouvelle notation (suite)

En conclusion UML™ est une bonne base :

Mais…​

Introduction à SysML

Si vous ne deviez lire qu’un seul chapitre, voilà ce qu’il faudrait retenir.

Fiche d’identité

fiche

SysML, c’est…​

Un ensemble de 9 types de diagrammes :

SysML, c’est…​ (suite)

SysML, c’est (suite) :

Un profil UML™ : C’est à dire une extension de cette notation, un ensemble de nouveaux concepts et éléments qui sont définis à partir des éléments de base d’UML™. Un exemple : le bloc SysML™ n’est qu’une redéfinition de la classe UML™.

Une notation : Une notation de plus en plus enseignée et connue et qui servira donc de plus en plus de référence à la modélisation des systèmes.

SysML, ce n’est pas…​

Une méthode
En effet, contrairement à ce que beaucoup pensent en l’abordant, SysML™ ne propose pas de démarche particulière de développement de système. C’est à la fois sa force (votre méthode existante pourra continuer à être utilisée) comme sa faiblesse car cette absence de guide méthodologique fait souvent défaut à son utilisation.
Un outil
Nous verrons en effet que SysML™ ne fait que ce qu’on veut bien en faire. Comme tout langage il est limité dans son pouvoir d’expression, mais surtout il reste une simple notation qu’il convient d’utiliser avec des outils et des démarches associées.

Ne dites pas "le SysML" mais tout simplement "SysML".

Différence avec UML

La figure suivante, tirée de la spécification, résume bien les liens entre SysML™ et UML™, à savoir que SysML™ reprend une partie seulement des concepts d’UML™ (appelée UML4SysML) en y ajoutant des concepts nouveaux.

diff
Figure 1. Liens entre UML et SysML

Qui est "derrière"?

Industrie
American Systems, BAE Systems, Boeing, Deere & Company, EADS Astrium, Eurostep, Israel Aircraft Industries, Lockheed Martin, Motorola, NIST, Northrop Grumman, oose.de, Raytheon, Thales, …​
Vendeurs d’outils
Artisan, EmbeddedPlus, Gentleware, IBM, Mentor Graphics, PivotPoint Technology, Sparx Systems, Vitech, …​
Autres organisations
AP-233, INCOSE, Georgia Institute of Technology, AFIS, …​

La liste complète des membres de {Lomg} est accessible à l’URL : http://www.omg.org/cgi-bin/apps/membersearch.pl

Organisation des différents diagrammes

SysML™ propose de couvrir la modélisation d’un système en 9 diagrammes. Ces diagrammes couvrent les aspects structurels et comportementaux du système ainsi que les exigences. Le diagramme suivant présente cette organisation en faisant au passage le lien avec ceux d’UML™ :

Figure4 1

Organisation (raccourcis)

Figure4 1 bis

Différence entre modèle et dessin

dessin slide

Diagramme de bloc

Par exemple dans ce diagramme les blocs ne respectent pas la syntaxe graphique de SysML™ :

Erreur : mauvais symboles graphiques pour les blocs
cordeuseContext

Pour rappel, la notation jmb : Personne permet de représenter un objet (une instance d’une classe ou d’un bloc). C’est donc une notation utilisée par exemple dans les participants d’un diagramme de séquence ou encore les parties d’un diagramme interne de bloc.

Donc dans le diagramme ci-dessus, l’acteur est correct (on peut mettre des acteurs dans un bdd, cf. OMG SysML v1.3 p.32), par contre les objets Block : …​ est une erreur de notation.

Solution : utiliser un outil (B)
cordeuseContextOK

Attention, il est tout à fait possible de représenter des instances dans un bdd (cf. OMG SysML v1.3 p.34), même si c’est très peu courant.

Outils SysML

Il existe un certain nombre d’outils permettant de réaliser des modèles SysML. Voici une liste non exhaustive :

Organisation

ExigencesStructureComportementTransverse

You are here! Organisation

Analyse

Conception

Implémentation

Cadre pour les diagrammes

Abordons quelques principes généraux de SysML™, c’est à dire des éléments indépendant d’un diagramme en particulier :

Cadre (suite)

Cadre (suite)

Dans l’exemple ci-dessous, le diagramme "Context_Overview" est un Block Definition Diagram (type bdd) qui représente un package, nommé "Context".

pacemaker context
Convention : Utilisation systématique des cartouches

Tout diagramme proposé pour décrire un système (dans une documentation par exemple) devrait posséder un entête précis.

Carte des concepts

Pour ceux qui cherchent à étudier un diagramme en particulier voici un plan de cette section (nous utilisons ici le "plan" vu lors de l’introduction de la [Matrice]) :

Table 1. Organisation
ExigencesStructureComportementTransverse

Organisation

pkg

pkg, bdd

pkg

Analyse, Conception, Implémentation [1]

req

bdd, ibd, sd, par

uc, sd, stm, act

par

Fondements

On abordera :

Le Package Diagram

Le diagramme de paquetage permet de représenter l’organisation des modèles en paquetages.

Les modèles peuvent être organisés selon toutes sortes de considération (cf. Les organisations possibles) :

Les différent types de packages

Il existe plusieurs types de package :

models
un package "top-level" dans une hiérarchie de packages
packages
le type le plus classique : un ensemble d’éléments de modèles
model librairies
un package prévu pour être réutilisé (importé) par d’autres éléments
views
un package spécial pour représenter les points de vue

Un point de vue (viewpoint) est utilisé pour matérialiser une perspective particulière de modélisation. Il possède des propriétés standardisés (concerns, language, purpose, etc.) et permettent d’indiquer qu’une vue (un packetage particulier, stéréotypé <<view>>) est conforme (dépendance <<conform>>) à un point de vue.

Les organisations possibles

Les modèles peuvent être organisés selon toutes sortes de considération :

Les organisations possibles (suite)

pkg organisation2

Les organisations possibles (suite)

pkg organisation modelview

Les organisations possibles (suite)

pkg organisation

Les organisations possibles (suite)

pkg topcased

Les organisations possibles (suite)

L’outil Modelio (System architect) propose, lors de la création d’un premier modèle une organisation "type" par défaut.

organisation

La notion de Namespaces

Un package permet de créer un espace de nommage pour tous les éléments qu’il contient. Ainsi, dans un package, on n’a pas à se soucier des noms des éléments. Même si d’autres utilisent les mêmes noms, il n’y aura pas ambiguité.

Définition : Namespace (OMG SysML v1.3, p. 23)

The package defines a namespace for the packageable elements.

Pour éviter toute ambiguité, on peut utiliser pour les éléments de modèles leur nom complet (Qualified name), c’est à dire le nom de l’élément préfixé par son (ou ses) package(s) (e.g., Structure::Products::Clock).

Dans les outils SysML™, il faut souvent demander explicitement à voir les noms complets (Qualified names) des éléments (la plupart du temps dans les options graphiques).

Les dépendances

Un certain nombre de dépendances peuvent exister entre des éléments de package ou entre les packages eux-mêmes :

Dependency
une dépendance "générale", non précisée,
représentée par une simple flèche pointillée ----->
Use
l’élément "utilise" celui à l’autre bout de la flèche (un type par exemple),
représentée par le stéréotype <<use>>

Les dépendances (suite)

Refine
l’élément est un raffinage (plus détaillé) de celui à l’autre bout de la flèche,
représentée par le stéréotype <<refine>>
Realization
l’élément est une "réalisation" (implémentation) de celui à l’autre bout de la flèche,
représentée par le stéréotype <<realize>>

Les dépendances (suite)

Allocation
l’élément (e.g., une activité ou un requirement) est "alloué" sur celui à l’autre bout de la flèche (un block la plupart du temps),
représentée par le stéréotype <<allocate>>

En résumé

SysML™ propose un certain nombre de mécanismes pour organiser les différents modèles, tirés pour la plupart d’UML™. Ces mécanismes seront plus faciles à comprendre au travers de leur utilisation concrète dans la suite.

Table 2. Organisation
ExigencesStructureComportementTransverse

Organisation

package

package

package

dependencies

…​

Questions de révision

  1. Quels sont les 5 types de dépendances entre packageable elements ?
  2. À quoi cela peut-il servir de définir les dépendances (donnez des exemples concrets) ?

Exigences

⇒ cf. slides dédiés

L’architecture du système

ExigencesStructure You are here!ComportementTransverse

Organisation

Analyse

Conception

Implémentation

Fondements

On abordera :

Organisation du système et des modèles

ExigencesStructureComportementTransverse

Organisation

You are here!

Analyse

Conception

Implémentation

En terme d’organisation, le mécanisme clef est celui de package. Celui-ci va permettre d’organiser les modèles, pas le système lui-même. Nous avons abordé cette organisation (cf. Le Package Diagram).

Pour l’organisation du système, on trouve le plus souvent :

Block Definition Diagrams

Principes de base

Un bdd peut représenter :

Principes de base (suite)

Un diagramme de bloc décrit les relations entre les blocs (compositions, généralisations, …​). Ce diagramme utilise les mêmes éléments que le diagramme de classe UML™.

pacemaker context

Principes de base (suite)

Un bloc est constitué d’un certain nombre de compartiments (Compartments) :

Properties
Equivalent UML™ des propriétés (e.g., attributs).
Operations
Les méthodes supportées par les instances du bloc.
Constraints
Les contraintes (cf. [contraintes])
Allocations
Les allocations (cf. Les aspects transversaux)
Requirements
Les exigences liées à ce bloc.
User defined
On peut définir ses propres compartiments.

Principes de base (suite)

constraints

Propriétés

On peut différencier 4 types de propriétés d’un bloc :

value properties
Des caractéristiques (quantifiables), aussi appelées simplement values
parts
Les éléments qui composent le bloc (cf. Internal Block Diagrams)
references
Les éléments auquel le bloc a accès (via des associations ou des agrégations)
constraint properties
Les contraintes que doivent respecter les propriétés (nous les verrons plus en détail, cf. Parametric Diagrams).

Les values sont ce qui se rapproche le plus des attributs de classes UML.

Value Types

Pour associer un type aux valeurs, SysML™ propose de définir des Value Types.

valueType

Associations entre blocs

Il existe deux types de relations entre blocs :

Association

Une association est un ensemble de liens permanents existant entre les instances de deux ou plusieurs blocs. On dira qu’une association lie plusieurs blocs ou que les blocs participent à l’association.

Une association possède plusieurs propriétés :

Dimension d’une association
Nombre de blocs mis en jeu par l’association
(binaire : 2, ternaire : 3, n-aire : n)

Association (suite)

Nom d’une association
Afin de clarifier les informations, il est important de nommer les associations. Il existe trois façons de nommer une association :

Association (suite)

Cardinalité
Indique à combien d’instances minimum et maximum du bloc d’en face est lié toute instance du bloc de départ. Elle est représentée par un couple (M..N).

Vers le code : que signifie vraiment une association?

En terme de logiciel, une association représente une contrainte sur la suite du développement : que ce soit un code (en langage orienté objet la plupart du temps) ou une base de donnée.

Pour reprendre l’exemple précédent, cela signifie concrètement au niveau d’un code par exemple que depuis une variable Produits on doit être capable d’accéder à une variable (correspondante) de type tableau (ou liste, ou …​) de Fournisseurs.

Exemple Java

Ce qui peut donner en java :

public class Produits
{
//Produits Attributes
private String idPro;
private String designation;
private float poids;

//Produits Associations
private List<Fournisseurs> fournisseurs;
...

Composition

En terme d’ingénierie système, on utilisera plutôt des associations spécifiques (l’agrégation et la composition).

aggreg comp

Composition (suite)

En terme d’Ingénierie Système, une composition indique que l’élément est une partie intégrante (on parle de part) du tout (un composant, comme le moteur d’une voiture par exemple) tandis q’une agrégation indique que l’élément est une partie "externe" (on parle de reference) comme la batterie d’un portable.

Composition (suite)

Un moyen simple en terme logiciel de déterminer si une association A→B est une association dirigée (navigable dans un sens), une agrégation ou une composition est de raisonner en terme d’implémentation :

  • c’est une agrégation si b est initialisé dans le constructeur de A
  • c’est une composition s’il est aussi détruit dans le destructeur de A
  • c’est une association dirigée simple si aucun des deux cas précédent ne s’applique.

Composition (suite)

compo

Généralisation/Spécialisation

Lorsque plusieurs blocs ont des caractéristiques en communs (propriétés, associations, comportement), il peut être utile de "factoriser" ces éléments en un bloc dont les autres vont "hériter". Quand on réalise ces liens hiérarchiques (on utilise souvent le terme "est un") en partant des blocs différents pour établir un nouveau bloc contenant les points communs on parle de généralisation. À l’inverse, quand on constate qu’un bloc possède réellement plusieurs déclinaisons différentes et que l’on créé alors des blocs spécifiques, on parle alors de spécialisation.

Généralisation/Spécialisation (suite)

genspec

On retrouve cette association entre blocs, mais aussi entre acteurs, cas d’utilisation, etc.

Internal Block Diagrams

Un ibd décrit la structure interne d’un bloc sous forme de :

parts
Les parties qui constituent le système (ses sous-systèmes)
ports
Elément d’interaction avec un bloc
connecteurs
Liens entre ports

Parts

Les parties sont représentés par les éléments au bout d’une composition dans un bdd.

Elles sont créés à la création du bloc qui les contient et sont détruites avec lui s’il est détruit (dépendance de vie).

Il ne s’agit pas de redessiner le BDD. Les parts sont des instances et non des classes (au sens objet).

Parts (suite)

On représente les parts comme des bloc en traits pleins et les references comme des blocs en trait pointillés.

parts

Parts (suite)

parts2

Ports (SysML 1.2)

La version SysML 1.5 de la spécification préconise l’abandon des ports tels que définis dans la version 1.2. Nous présentons les nouvelles notions dans la section qui suit.

Néanmoins, de par l’importance des exemples qui utilisent les notions habituelles de ports, et vu que tous les outils ne supportent pas encore les nouveaux ports, nous indiquons ici leur définition et recommandons pour l’instant de les utiliser.

Ports (suite)

Les ports :

Ports (suite)

Les ports définissent les points d’interaction offerts (<<provided>>) et requis (<<required>>) entre les blocs.
Les connecteurs peuvent traverser les "frontières" sans exiger de ports à chaque hiérarchie.

Ports (suite)

ports flots
Définition : Ports (OMG SysML v1.3, p. 57)

Ports are points at which external entities can connect to and interact with a block in different or more limited ways than connecting directly to the block itself.

Ports (suite)

flots

Ports (suite)

Les ports peuvent être de nature classique (comme en UML™) et représenter la fourniture ou le besoin de services. On parle alors de *standard flows*.

Ports (suite)

Ils peuvent aussi être de nature "flux physique", on parle de *flow ports*.

Les Flux peuvent être :

Ports (suite)

Un flow port atomique ne spécifie qu’un seul type de flux en entrée ou en sortie (ou les deux), la direction étant simplement indiquée par une flèche à l’intérieur du carré représentant le port. Il peut être typé par un bloc ou un Value Type représentant le type d’élément pouvant circuler en entrée ou en sortie du port.

Ports (depuis SysML 1.3)

La spécification SysML 1.5 introduit les concepts de:

proxy port
Ils doivent remplacer les ports 1.2 (ports de flots et ports standards) en en reprenant les caractéristiques et en ajoutant la possibilité d’imbrication et de spécification renforcée.

Ports (suite)

full port
En fait il s’agit du même concept qu’une partie qui serait exposée à l’extérieur.

Ports (suite)

Pour une discussion sur les différences entre les deux ports : http://model-based-systems-engineering.com/2013/09/23/sysml-full-ports-versus-proxy-ports/

Parametric Diagrams

Afin de capturer de manière précise les contraintes entre valeurs, ou encore les liens entre les sorties et les entrées d’un bloc, SysML™ utilise trois concepts clefs :

Contraintes

C’est un bloc particulier :

Contraintes (suite)

constraints
Définition : ConstraintBlock (OMG SysML v1.3, p. 86)

A constraint block is a block that packages the statement of a constraint so it may be applied in a reusable way to constrain properties of other blocks.

Diagramme paramétrique

C’est une forme particulière de Internal Block Definition

param

Value Binding

Une fois les contraintes exprimées, il faut lier les paramètres (formels) à des valeurs (paramètre réel). C’est l’objet des Value Binding.

Pour assigner des valeurs spécifiques, on utilise des Block Configurations;

blockconf

Diagrammes de séquence système

Les diagrammes de séquence système (DSS) sont des Sequence Diagrams UML™ classiques où seul le système est représenté comme une boîte noire en interaction avec son environnement (les utilisateurs généralement).

Il permet de décrire les scénarios des cas d’utilisation sans entrer dans les détails. Il convient donc mieux à l’ingénierie système qu’un diagramme de séquence classique (cf. section sur les Sequence Diagrams).

dss

En résumé

En résumé, il existe plusieurs diagrammes permettant d’exprimer la structure du système à concevoir. En fonction du niveau de détail nécessaire on peut voir les sous-systèmes comme des boîtes noires (des blocs) ou comme des boîtes blanches (grâce à un ibd).

ExigencesStructureComportementTransverse

Organisation

pkg

Analyse

bdd par

Conception

bdd par ibd dss

Implémentation

bdd par ibd dss

Questions de révision

tuxteacher

Quelles sont les différences entre une association dirigée (->), une composition (losange noir) et l’agrégation (losange blanc) ?

Puisqu’un bdd me donne souvent la liste des sous-systèmes (liens de composition), pourquoi ai-je besoin d’un ibd ?

Le comportement du système

ExigencesStructureComportement You are here!Transverse

Organisation

Analyse

Conception

Implémentation

Fondements

On abordera :

Use Case Diagrams

Acteurs
Les principaux éléments extérieurs au système considéré, et participant qui participent (on parle parfois d’acteurs principaux). Ils ont souvent un rôle. ou qui bénéficient (on parle alors d’acteurs secondaires) du système.
Cas d’utilisation
représente un ensemble d’actions réalisées par le système intéressant pour au moins un acteur

Use Case Diagrams (suite)

Association
participation d’un acteur à un cas d’utilisation.
Sujet
le domaine étudié (qui peut être une partie seulement de tout le système, pas forcément modélisé dans son ensemble)

Use Case Diagrams (suite)

Un acteur représente un rôle joué par un utilisateur humain. Il faut donc plutôt raisonner sur les rôles que sur les personnes elles-mêmes pour identifier les acteurs.

Le Diagramme des Cas d’Utilisation

Le Diagramme des Cas d’Utilisation est un diagramme UML™ permettant de représenter :

Cas d’Utilisation (Use Case)

Un cas d’utilisation représente un ensemble de scénarios que le système doit exécuter pour produire un résultat observable par un acteur.

Exemple de cas d’utilisation (UML)

Retrait par carte bancaire

Scénario principal
L’UC démarre lorsque le Guichet Automatique Bancaire (GAB) demande au client son numéro confidentiel après l’introduction de sa CB. Le client entre son code et valide son entrée. Le GAB contrôle la validité du code. Si le code est valide, le GAB autorise le retrait et l’UC se termine.
Scénario alternatif n°1
Le client peut à tout instant annuler l’opération. La carte est éjectée et l’UC se termine.
Exemple de codification de l’UC
UC01 ou RetraitCB (pour Retrait par carte bleue)

Précisions

Un cas d’utilisation peut être précisé par :

Dans les outils, cette "précision" se manifeste par le fait que l’on "attache" généralement un diagramme de séquence à un cas d’utilisation (clic droit sur un Use Case → nouveau sd).

Acteur

Un acteur peut être une personne, un ensemble de personnes, un logiciel, un processus qui interagit avec un ou plusieurs UC.

On peut trouver plusieurs types d’acteurs :

On peut utiliser des liens de généralisation/spécialisation entre acteurs pour représenter les possibilités pour le spécialisé d’avoir les mêmes prérogatives (notamment en terme d’utilisation du système) que le généralisé.

Relations entre acteurs et Use Case

En général, une simple association relie acteurs et Use Case. On peut également orienter ces associations en plaçant une direction (flèche vide) au bout de l’association.

ucexp1

Relations entre Use Case

Après avoir listé les cas d’utilisation, il est utile de les organiser et de montrer les relations entre eux. Plusieurs relations sont possibles :

Relations entre Use Case (suite)

Extension (<<extend>>)
Indique que le Use Case source est éventuellement exécutée en complément du Use Case destination (cas particulier, erreur…​). Le point précis où l’extension peut se produire est appelé extension point (surtout utile quand il existe plusieurs extensions pour un même cas)

Relations entre Use Case (suite)

Inclusion (<<include>>)
Indique que le Use Case est inclus obligatoirement dans un autre Use Case (notion de sous-fonction par exemple)

Relations entre Use Case (suite)

Généralisation
Relation entre un Use Case général et un autre plus spécialisé qui hérite de ses caractéristiques et en rajoute (différents modes d’utilisation d’un système par exemple, ou encore différents acteurs impliqués)

Relations entre Use Case (suite)

Diagramme d'UC

On n’utilise généralement <<include>> que dans le cas où le sous-cas d’utilisation est inclut dans plusieurs UC. Si ce n’est pas le cas, il est généralement englobé dans l’UC.

Pour construire un UC (de manière générale)

  1. identifier les acteurs
  2. identifier les cas d’utilisation
  3. structurer en packages
  4. finaliser les diagrammes de cas d’utilisation (ajouter les relations)

Certains méthodologistes (comme Tim Weilkiens) préconisent de ne pas utiliser les acteurs et les cas d’utilisation (cf. son blog)

Exemples complets (UML) : Gestion des notes

Exemple de Diagramme d'UC

Sequence Diagrams

Généralités

Il permet de :

Les éléments qui composent ce diagramme sont :

Sequence Diagrams (suite)

Participants
les éléments en interaction (des blocs généralement)
Lignes de vie
des lignes verticales qui permettent d’indiquer un départ ou une arrivée d’interaction
Barres d’activation
pour matérialiser quand l’élément est actif
Messages
ce qui "circule" d’un élément à l’autre (signal, appel de méthode)

Les participants (et leur ligne de vie) représentent des instances de blocs (souvent "anonymes").

Exemple

dsexp1 Exemple de diagramme de séquence

Notions avancées

On peut également représenter des instructions itératives et conditionnelles au travers de cadres d’interaction :

Notions avancées (suite)

Un algorithme

Notions avancées (suite)

Sa modélisation

Exemple de conceptions

Le diagramme de séquences est un diagramme utile pour montrer les "responsabilités" de certains objets par rapport aux autres. Dans un code logiciel, on peut y déceler plus facilement que tel objet est plus chargé que d’autres. Les deux diagrammes suivants (tirés de [Fowler2004]) montrent deux conceptions différentes possibles pour l’implémentation d’une même fonctionnalité. On mesure visuellement assez bien la différence entre la version "centralisée" ([fowler1]) et la version "objet" ([fowler2]).

Exemple de conceptions (suite)

Conception 'centralisée'

Exemple de conceptions (suite)

Conception 'objet'

On utilise le diagramme de séquence pour représenter des algorithmes et des séquencements temporels. Lorsque le comportement se rapproche plus d’un flot, on utilise le diagramme d’activité (cf. section sur le Diagrammes d’activité).

Lien entre UC, DSS et DS

La décomposition hiérarchique permet une description "TOP-DOWN" du système à réaliser.

On fait un Diagramme de Séquence Système pour chaque cas d’utilisation (issu du Diagramme d’UC) pour déterminer les échanges d’informations entre l’acteur et le système.

Ensuite on fait un Diagramme de Séquence (DS) pour décrire comment les blocs composant le système (issus du bdd) collaborent pour réaliser le traitement demandé.

Lien entre UC, DSS et DS (suite)

Diagramme d'UC

Lien entre UC, DSS et DS (suite)

Le DSS correspondant

Lien entre UC, DSS et DS (suite)

Le DS correspondant

Diagramme d’états

SysML™ a repris le concept, déjà connu en UML™, de machine à états (State Machines). Ce diagramme représente les différents états possibles d’un bloc particulier, et comment ce bloc réagit à des événements en fonction de son état courant (en passant éventuellement dans un nouvel état). Cette réaction (nommée transition) possède un événement déclencheur, une condition (garde), un effet et un état cible.

Diagramme d’états (suite)

Le diagramme d’états comprend également deux pseudo-états :

Diagramme d’états (suite)

Un diagramme d'état

Diagramme d’états (suite)

Lorsqu’un état nécessite lui-même plus de détails, on créé un état composite (aussi appelé super-état) qui est lui-même une machine à état. On peut ainsi factoriser des transitions déclenchées par le même événement (et amenant vers le même état cible), tout en spécifiant des transitions particulières entre les sous-états. Il est également possible d’attacher un diagramme d’état (composite) à un état pour garder une représentation hiérarchique.

Diagramme d’états (suite)

Un diagramme d’état peut représenter des régions concurrentes (dont les activités peuvent évoluer en parallèle), graphiquement représentées par des zones séparées par des traits pointillés. Chaque région contient ses propres états et transitions.

Diagramme d’états (suite)

Il existe encore d’autres concepts avancés que nous ne présenterons pas dans cette introduction car ils sont beaucoup moins utilisés (entry, exit, transition interne, etc.).

Diagrammes d’activité

Les diagrammes d’activité (Activity Diagrams) est utilisé pour représenter les flots de données et de contrôle entre les actions. Il est utilisé pour raffiner en général un cas d’utilisation. Il est utilisé pour l’expression de la logique de contrôle et d’entrées/sorties. Le diagramme d’activité sert non seulement à préciser la séquence d’actions à réaliser, mais aussi ce qui est produit, consommé ou transformé au cours de l’exécution de cette activité.

act pcmk1

Diagramme d’activités (suite)

Les éléments de base du diagramme d’activité sont :

Actions

Les actions sont les unités fondamentales pour spécifier les comportements en SysML™. Une action représente un traitement ou une transformation. Les actions sont contenues dans les activités, qui leur servent alors de contexte.

Flots

Un flot de contrôle permet le contrôle de l’exécution des noeuds d’activités. Les flots de contrôle sont des flèches reliant deux noeuds (actions, décisions, etc.).

Le diagramme d’activité permet également d’utiliser des flots d’objets (reliant une action et un objet consommé ou produit). Les object flow, associés aux broches d’entrée/sortie (input/output pin) permettent alors de décrire les transformations sur les objets manipulés.

Un flot continu

Pour permettre la modélisation des flots continus, SysML™ ajoute à UML™ la possibilité de caractériser la nature du débit qui circule sur le flot : continu (par exemple, courant électrique, fluide, etc.) ou discret (par exemple, évenements, requêtes, etc.). On utilise pour cela des stéréotypes : <<continuous>> et <<discrete>>. Par défaut, un flot est supposé discret.

Définition : FlowProperty (OMG SysML v1.3, p. 63)

A FlowProperty signifies a single flow element to/from a block. A flow property has the same notation as a Property only with a direction prefix (in | out | inout). Flow properties are listed in a compartment labeled flow properties.

Décision

Une décision est un noeud de contrôle représentant un choix dynamique entre plusieurs conditions (mutuellement exclusives). Elle est représentée par un losange qui possède un arc entrant et plusieurs arcs sortants. Il existe plusieurs noeuds de contrôle (cf. [Control]) :

Décision (suite)

fork
Un fork est un noeud de contrôle représentant un débranchement parallèle. Il est représenté par une barre (horizontale ou verticale) qui possède un arc entrant et plusieurs arcs sortants. Le fork duplique le "jeton" entrant sur chaque flot sortant. Les jetons sur les arcs sortants sont indépendants et concurrents.

Décision (suite)

join
Un join est un noeud de contrôle structuré représentant une synchronisation entre actions (rendez-vous). Il est représenté par une barre (horizontale ou verticale) qui possède un arc sortant et plusieurs arcs entrants. Le join ne produit son jeton de sortie que lorsqu’un jeton est disponible sur chaque flot entrant (d’où la synchronisation).

Décision (suite)

flow final
Contrairement à la fin d’activité qui est globale à l’activité, la fin de flot est locale au flot concerné et n’a pas d’effet sur l’activité englobante.

Décision (suite)

merge
La fusion est l’inverse de la décision : le même symbole du losange, mais cette fois-ci avec plusieurs flots entrants et un seul sortant.
flow ctrl

Pour se rapprocher de SADT/SART, la norme prévoit la possibilité d’utiliser les pointillés pour les flux de contrôle.

Control flow may be notated with a dashed line and stick arrowhead…​

Réutilisation

Les activités peuvent être réutilisées à travers des actions d’appel (callBehaviorAction). L’action d’appel est représentée graphiquement par une fourche à droite de la boîte d’action, ainsi que par la chaîne : nom d’action : nom d’activité. SysML™ propose encore bien d’autres concepts et notations, comme la région interruptible, la région d’expansion ou encore les flots de type stream qui sortent du cadre de ce livre d’introduction.

act call

En résumé

Il existe de nombreux diagrammes pour exprimer les comportements. Ces modèles sont importants dans la mesure où ils peuvent servir à valider le futur système vis-à-vis de ces comportements exprimés. Ils ne sont donc véritablement utiles que lorsqu’ils sont couplés à des outils de simulation ou d’analyse (cf. [Analyse]).

Table 3. Place du Comportement
ExigencesStructureComportementTransverse

Organisation

pkg

Analyse

uc sd

Conception

dss sd act

Implémentation

stm

Les aspects transversaux

Aspects transversaux

Table 4. Aspects transversaux
ExigencesStructureComportementTransverse You are here!

Organisation

Analyse

Conception

Implémentation

Fondements

On abordera ici les aspects transversaux comme :

Traçabilité des exigences

Nous avons vu déjà un certain nombre de mécanismes SysML™ qui permettent de tracer les exigences. Nous les regroupons ici dans une matrice spécifique (qui se lit dans le sens des relations, par exemple un élément de structure comme un bloc <<satisfy>> une exigence).

Table 5. Traçabilité
ExigencesStructureComportement

Exigences

<<deriveRqt>>, <<refine>>, <<copy>>

Structure

<<allocate>>, <<satisfy>>

<<allocate>>

Comportement

<<refine>>

Comme indiqué dans le tableau ci-dessus, en général, le lien de raffinement est utilisé entre une exigence et un élément comportemental (état, activité, uc, etc.) tandis que l’allocation concerne principalement les éléments de structures.

XXX Mettre un exemple avec tous ces liens. XXX

Mécanismes d’allocation

Un mécanisme nouveau en SysML™ et important pour {lis} est le mécanisme d'allocation. Il permet de préciser quel élément conceptuel (comme un comportement ou une activité) est alloué sur quel élément physique.

Il est possible d’exprimer cette allocation de plusieurs manières.

Parler du <<AllocatedTo>>, compartiments des blocs et autres annotations. Parler des zones d’allocation dans les machines à états où les diagrammes d’activités par exemple. Parler des <<allocate>>.

Diagramme paramétrique

C’est une forme particulière de Internal Block Definition (cf. Parametric Diagrams). On y retrouve les contraintes, déjà vues (cf. [contraintes]), mais cette fois-ci on a la représentation graphique des liens entre les données.

param

Diagramme paramétrique (suite)

Il est regrettable que ce diagramme soit le moins utilisé (cf. [enquete]).

Certaines approchent (cf. [MeDICIS]) utilisent des feuilles excel pour traduire les diagrammes paramétriques et contrôler l’impact des changements de valeurs de tel ou tel paramètre.

En résumé

En résumé l’expression du comportement du système en SysML™ est très similaire à ce qui est fait dans UML™. On retrouve néanmoins le renforcement des liens entre éléments de modèles par les dépendances précises et les allocations. Un autre élément de renforcement entre éléments de modèles concerne le fait qu’un diagramme comportemental (comme une machine à état) est attachée à un élément bien précis (par exemple un bloc). Ces liens apparaissent entre blocs et machines à état, entre cas d’utilisation et diagrammes de séquence ou d’activité, etc.

Questions de révision

tuxteacher

Quelles sont les différences entre <<satisfy>> et <<allocate>> ?

Pourquoi est-il important de relier un use case à au moins un requirement ?

L’inverse est-il aussi important ?

Questions de révision

Éléments de réponses :

  1. Quelles sont les différences entre <<satisfy>> et <<allocate>> ? La satisfaction concerne une propriété (d’une solution vis à vis d’un problème) quand l’allocation permet de rajouter un information sur qui fait quoi.
  2. Pourquoi est-il important de relier un use case à au moins un requirement ? Sinon on peut se demander s’il s’agit vraiment d’une utilisation du système qui nous concerne (une exigence a-t’elle été oubliée?).
  3. L’inverse est-il aussi important ? Encore plus je dirais, au sens où une exigence n’est couverte par aucune utilisation du système (cela peut arriver lors d’une exigence non satisfiable!)

The End    (for now)

Credit

Photo Credit: https://www.pexels.com